Forum PHP.pl

Pytania o streszczenie wątku, posty z "genialnymi" skryptami nadającymi się tylko na przedszkole i inne tego typu, będą bez ostrzeżenia usuwane przez moderatorów.
To mówiłem ja, Jarząbek... znaczy nospor dnia 2007-12-10
-------------------------------------------------------------------------------

SQL Injection (zwane też "SQL Insertion") to (rzekomo) najprostszy sposób włamu na stronę. Spowodowany jest on niepełnym sformułowaniem zapytań do MySQL.

Przykład. Dajemy na stronie możliwość edycji profilu. Zapytanie do SQL wygląda następująco:

[PHP] pobierz, plaintext 
<?php
$query = &#092;"update uzytkownicy set pole='$dane' where id='$id'\";
?>
[PHP] pobierz, plaintext 

Osoba włamująca się na stronę umieszcza całkiem prosty, odpowiedni ciąg znaków/poleceń w dowolnym polu edycji tego profilu, który wygląda np. tak (dla zmiany hasła użytkownika o dowolnie wybranym, przez atakującego numerze ID):

[PHP] pobierz, plaintext 
<?php
', haslo='nowe_haslo' WHERE id = '1
?>
[PHP] pobierz, plaintext 

W taki oto prosty sposób, osoba atakująca zmieniła hasło użytkownikowi o ID=1 (zazwyczaj administrator). W podobny sposób można również wyciągnąć dowolne dane z tabeli SQL.

W każdym razie. Poszperałem, pomyślałem i zebrałem wszystko do kupy. Zamieszczam to tutaj razem, oraz proszę o rozbudowanie tego topica, gdyż nie znalazłem na tym forum więcej informacji o "SQL Injection".

Oto co możemy dokonać:
1. Możemy sformułować nasze zapytanie do SQL tak:

[PHP] pobierz, plaintext 
<?php
$query = 'update `uzytkownicy` set `pole`=\"'.$dane.'\" where `id`=\"'.$id.'\";';
?>
[PHP] pobierz, plaintext 

2. Przy wstawianiu numerów ID do zapytań należy stosować tzw. rzutowanie typów:

[PHP] pobierz, plaintext 
<?php
$id = (int)$_GET['id'];
// lub
$id = intval($_GET['id']);
?>
[PHP] pobierz, plaintext 

3. Przy wstawianiu tekstów, należy wyciąć niebezpieczne znaki przy pomocy funkcji:

[PHP] pobierz, plaintext 
<?php
$string = mysql_real_escape_string($_POST['string']); // PHP5
 
$string = mysql_escape_string($_POST['string']); /* lub */ $string = addslashes($_POST['string']); // PHP4
?>
[PHP] pobierz, plaintext 

Może nie ma tego dużo, ale jest to już jakaś podstawa do zabezpieczenia strony/skryptu przed prostym i niezwykle niebezpiecznym, SQL Injection. Proszę osoby obeznane w tym temacie, aby dopisały tu własne propozycje metod zabezpieczenia się przed tym atakiem.

Ten post edytował Najki 14.02.2008, 10:04:12

Jeśli będę używał PDO zamiast MySQL do łączenia się z bazą danych to jest mniejsze prawdopodobieństwo, że ktoś może wykorzystać SQL Injection ?

Po pierwsze nie zamiast MySQL, co najwyżej mysql_ (IMG:style_emoticons/default/smile.gif) .
Po drugie tylko jeśli będziesz używał zapytań preparowanych i podpinania parametrów, wtedy prawdopodobieństwo -> 0.

Ten post edytował Mephistofeles 14.07.2012, 22:46:02

A gdzie mogę zobaczyć przykład zapytań preparowanych ?

Stronę wcześniej w tym temacie (IMG:style_emoticons/default/biggrin.gif) .

Czyli ten kod jest preparowaniem zmiennych, tak ?

[PHP] pobierz, plaintext 
$pdo = new PDO("mysql:host=localhost;dbanme=xxx", "root", "");
$zap = $pdo->prepare("INSERT INTO `uzytkownicy` (`login`, `haslo`, `email`) VALUES(:login, :haslo, :email)");
$zap->bindValue(":login", $_POST['login'], PDO::PARAM_STR);
$zap->bindValue(":haslo", $_POST['haslo'], PDO::PARAM_STR);
$zap->bindValue(":email", $_POST['email'], PDO::PARAM_STR);
$zap->execute();
$zap->closeCursor();
[PHP] pobierz, plaintext 

tak.

Dobra, po przeczytaniu lektury w tym temacie od dnia dzisiejszego będę korzystał z PDO.

Dzięki (IMG:style_emoticons/default/smile.gif)

A w jaki bezpieczny sposób wyciągać dane użytkowników za pomocą PDO ?

Witam
Chciałbym potwierdzić kilka rzeczy:
1. Czy funkcja mysqli_real_escape_string jest tak samo nic niewarta jak mysql_real_escape_string? Oczywiście na dzień dzisiejszy (PHP 5.4).
2. Czy w przypadku liczb całkowitych rzutowanie na inta jest wystarczającym zabezpieczeniem czy są jakieś cudowne metody pozwalające obejść to?
3. Czy htmlentities chroni przed XSS?
I od razu chciałbym zaznaczyć że nie jestem upartym durniem broniącym się rękami i nogami przez używaniem prepared statements, tylko jakiś czas temu przeczytałem to i stwierdzenie tam zawarte nie daje mi spokoju:

Obie są stworzone do tego, co mają robić, i stwierdzenie, że są nic nie warte to pitolenie po całości.



Wystarczy



Między innymi tak.

Dzięki z szybką i konkretną odpowiedz.
Co do 1. to chyba zostałem źle zrozumiany też wydaje mi się (bo brak mi wiedzy na ten temat) że te funkcja działa jak powinna, lecz wcześniej w tym wątku, albo gdzieś indziej, wyczytałem że ma problemy z kodowaniem znaków itp. itd.
To jeszcze tak dla pewności - używanie mysqli_real_escape_string jest tak samo efektywne (albo chociaż porównywalne) z używaniem prepared statements? Oczywiście jeśli chodzi o zabezpieczenie przez SQL Injection.

Musisz przeczytać do czego służy jedno i drugie... bo jak w ciemno będziesz wszędzie stosował "funkcje zabezpieczające" nie rozumiejąc co one robią, to prawdopodobnie i tak zostawisz luki, pomimo ich zastosowania.

Na dobrą sprawę moim problemem nie jest niewiedza jeśli chodzi o techniki obrony przed SQL Injection, chodzi bardziej o to że nie mam pojęcia jak wygląda taki atak (hakowanie mnie kompletnie nie interesuje), oczywiście poza teorią i prostymi przykładami - tylko jak dla mnie przed tym chroniło magic quotes, a tu czytam że w 5.4 zostało praktycznie rzecz ujmując wywalone. Przez co trochę zgłupiałem.
Ale poczytałem na spokojnie i rozwiałem większość swoich wątpliwości. Swoją drogą polecam tą stronę - wszystko w jednym miejscu i konkretnie na temat.
Mam jeszcze dwa pytania na które nie znalazłem konkretnych odpowiedzi.
W przypadku gdy chcę umieścić w bazie treść np. komentarza, posta, wiadomości itp. czyli gdy jest duża dowolność wpisywanych danych oraz ma być to później wyświetlone. Widzę dwa rozwiązania:
1. Zdekodować taką treść używając htmlentities i zapisać w takiej postaci w bazie. Niby nie jest to złe rozwiązanie ale ciężko będzie takie coś edytować z poziomu bazy danych.
2. Zastosować przed umieszczaniem w bazie mysqli_real_escape_string, a przy wyświetleniu użyć htmlentities. Nie ma to wady pierwszej metody ale nie jestem pewien czy samo mysqli_real_escape_string wystarczy.
Czy do switcha można wystrzyknąć złośliwy kod? Czyli czy takie coś:

[PHP] pobierz, plaintext 
switch($_GET['cos'])
{ ... }
[PHP] pobierz, plaintext 

jest potencjalnie niebezpieczne? Wiem że to ogólnie zła praktyka bo uczy złych nawyków, ale chodzi mi konkretnie czy switch jest narażony na taki atak.

Ten post edytował Cadmer 22.01.2013, 17:50:25

1 metoda odpada zupełnie, bo jest to bardzo zła praktyka, jeśli chodzi o cały projekt.

Co do reszty, przeanalizuj poniższy przykład:

[PHP] pobierz, plaintext 
<?php
 
// ....
 
$user_id = $_GET['user_id'];
$result = mysql_query('SELECT * FROM users WHERE id = '.mysql_real_escape_string($user_id));
 
// .....
 
?>
[PHP] pobierz, plaintext 

I sam mi odpowiedz na pytanie czemu ten urywek kodu jest podatny na ataki.



To też zależy. Z reguły nie, ale w przypadku udziwniania, też można zostawić lukę pozwalającą na włamanie.

Cóż można tam wstawić ID jakiegokolwiek użytkownika, co niekoniecznie jest błędem zależy co miałby ten kod robić. Nie powinno się raczej nigdy za to wybierać wszystkich kolumn z tabeli przy pomocy * z wielu powodów. Jeśli chodziło Ci o coś innego to tak jak pisałem wcześniej nie znam się na magicznych jak dla mnie sposobach wczepiania kodu zapytań.

Mógłbyś jakoś rozwinąć ? Właśnie jestem na etapie 'zabezpieczania' danych z postów i komentarzy i miałem zamiar użyć htmlspecialchars lub htmlentities. Oczywiście nie w kontekście SQL Injection, bo od tego mam PDO, ale np ataków XSS.

Ten post edytował Piotrbaz 3.02.2013, 18:07:07

Nie, zupełnie nie o to chodzi. Jako user_id podstaw sobie (zakładam, że w tabeli są kolumny id, username, password):



I zobacz co się stanie. Zabezpieczone przez mysql_real_escape_string(), a luka nadal jest. Magia, co?




Dane do wyświetlania zabezpiecza się właśnie przy wyświetlaniu, a nie ładuje do bazy już w zmienionej formie. Chodzi o integralność danych i czytelność tego co wpisują użytkownicy.

Ten post edytował pyro 3.02.2013, 21:42:13

No ok, czyli htmlspecialchars() stosuje przed wyświetleniem danych użytkownikowi. Czy przed zapisem danych do bazy ograniczam się tylko zabezpieczeniem przed SQL Injection ? (co załatwia podpinanie w PDO)

Ten post edytował Piotrbaz 3.02.2013, 23:12:03

Tak, prepared statements w PDO powinny załatwić sprawę. No chyba że integer przez przypadek potraktujesz jako string.

Ten post edytował pyro 3.02.2013, 23:19:18

Czesc,

troche tego duzo, szczerze, nie mam czasu czytac wszystkich stron.Ale mam pytanie apropo mysql_real_escape_string.
Wszyscy pisza, zeby uzywac do zmiennych przed wstawieniem do zapytania...
a nie mozna finalnego zapytania w calosci przepuscic przez to? Czy to bedzie mialo jakis nieoczekiwany efekt?

Zostaw te bzdury zaczynające się od mysql_* w manualu i przejdź na PDO, a nie będziesz mieć takich problemów.